Modern operating systems (OSs) come with build in support for reprographic devices such as printers, scanners, facsimile machines, multi-functional devices (these combine two or more functions of the former and usually also of copiers). Many software applications rely on this OS support for providing print, scan, and facsimile services. Especially for printing this is the case. Nowadays, the only software applications not relying on such OS support, either do not provide such services, for example, you cannot print directly from the application, or are specialised applications such as dedicated print job submitters which often function only with a limited number of device models.
The more generic applications typically make use of device drivers, such as printer drivers, to make use of these services. These device drivers may still be application specific, but in general these device drivers are installed on the system level in the OS in order to provide their services to a wide range of applications.
These device drivers are mainly responsible for two tasks:
1) Translating between a device independent graphics format and a device specific graphics format.
2) Translating generic device commands into device specific device commands understood by the specific device supported by the driver, and vice versa translating messages (for example status messages) received from the device into platform (OS) specific messages.
For example, an application may internally use a generic graphics format such as JPEG or some proprietary format and use the OS's print API to call API specific draw commands. These draw commands are typically not understood by a printer. It is a printer driver that translates these draw commands into specific printer “draw commands”, which is called the “print data”. In most modern electrophotography and inkjet printers these specific printer draw commands are in the form of a page or document specification in a Page Description Language (PDL) that is understood by the specific printer model (i.e. the PDL is the specific graphics format understood by the printer. Furthermore, the printer driver is responsible for translating settings the user is making (such as duplex printing, n-up printing) into job settings that are typically gathered in a job ticket. Finally, the print data and the job ticket are sent by the printer driver to the printer using the appropriate device specific device commands.
A disadvantage of the known architecture is that the device drivers are device specific. Of course this is by nature. It is the responsibility of the device driver to translate between a generic environment provided by the host OS and the device specific environment implemented in the specific device. However, this also means that as soon as anything changes with regard to the specification of the print data or the device commands, the device driver needs to reflect those changes. This means for example, that even if a company only has a single printer, and the printer firmware is upgraded providing some additional functionality, the printer drivers of all workstations that wish to print to this printer, require updating. Furthermore, if printers are employed of multiple printer models, every device model requires a specific device driver.
Although this disadvantage relates both to changes in the specification of the print data as well as the device commands, the former is nowadays mostly standardised in more-or-less stable PDL specifications. Therefore, inhere we will only address the latter.
The problem of requiring new device drivers when device capabilities change has been partially addressed in the prior art by introducing a mechanism for the device and the device driver to send a list of device capabilities from the device to the device driver allowing the device driver to adapt to changes in the devices capabilities. Although an improvement, this solution is still beyond ideal as these device capabilities are specified to the driver as a setting identifier such as a name, with corresponding acceptable values for the setting. This means that the device driver usually has no understanding of the meaning of these settings or the acceptable values, at least not for settings that were not foreseen when the device driver was written. It therefore just acts as a pass-through between the user and the device. It is up to the user to interpret the settings and the corresponding values.
The object of the present invention is to overcome or mitigate these drawbacks of the prior art.